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ABSTRACT 

This  paper  brings  together  in  a  single  coherent  organization  a 
number  of  diverse  compiler  implementation  techniques.  Some  inherent 
structure  that  guides  the  fragmentation  of  a  complex  compiler  into 
simpler  modules  is  thereby  exposed.  The  greater  part  of  the  paper 
is  taken  up  with  the  grammatical  specification  and  manipulation  of 
inter-modular  tables  and  languages  such  as  token  strings  and  compu¬ 


tation  trees. 
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1.  COMPILER  MODULARIZATION 


A  compiler  is  a  program,  written  in  an  implementation  language,  accepting 
text  in  a  source  language  and  producing  text  in  a  target  language.  A  source 
text  constitutes  a  program  or  procedure  and  the  target  text  is  a  machine  language 
version  of  the  source  text,  suitable  for  loading  into  main  memory  for  execution. 

Generally  speaking,  the  more  complex  the  source  language,  the  higher  the 
payoff  in  making  the  compiler  elaborate.  And  the  more  elaborate  the  compiler, 
the  more  necessary  it  becomes  to  apply  the  techniques  of  structured  programming, 
such  as  modularization. 

The  use  of  structured  techniques  is,  of  course,  dependent  on  the  implementation 
language  being  able  to  express  structure.  Higher  level  system  implementation 
languages  are  now  being  developed  by  various  people.  However,  now  is  not  the 
time,  nor  is  this  the  place  to  review  such  efforts.  We  will  simply  assume  that 
a  good  implementation  language  is  available. 

The  use  of  structured  techniques  also  depends  upon  taking  advantage  of 
the  inherent  structure  of  the  compiling  algorithm.  One  purpose  of  this  paper 
is  to  display  some  of  the  natural  boundaries  found  in  compilers,  thus  providing 
guidance  for  fragmenting  a  compiler  into  modules. 

We  must  keep  in  mind  that  there  are  at  least  three  different  kinds  of 
modules  corresponding  to  three  different  reasons  for  structuring  a  program. 

One  modularization  is  reflected  in  the  documentation.  It  aids  in  understanding 
the  program.  Concepts  are  grouped  where  a  common  structure  or  algorithm  can 
be  applied.  For  example,  a  program  may  use  a  large  number  of  queues.  They 
can  then  form  a  module  for  documentation. 

A  second  modularization  is  reflected  in  the  implementation  language 
text  of  the  compiler.  It  aids  in  the  task  of  writing  the  compiler.  These 
modules  are  procedural  in  nature.  They  have  well  defined  tasks  and  are  as 
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independent  as  possible. 

A  third  modularization  is  reflected  in  the  run-time  memory  management. 

It  aids  in  running  the  compiler  in  a  limited  amount  of  main  memory.  The 
run-time  modules  are  code  and  data.  They  may  be  managed  as  passes  or  by 
more  sophisticated  schemes  such  as  those  of  the  Burroughs  MCP  or  IBM  TSS. 

Since  the  reasons  to  modularize  are  quite  different,  there  is  no  particular 
reason  to  expect  one  modularization  to  satisfy  all  requirements,  but  there 
are  reasons  to  expect  some  relationships.  For  instance,  if  two  modules  are 

> 

independent  while  being  written,  it  is  likely  that  they  will  be  independent 
while  running,  hence  they  can  afford  to  be  in  different  memory  modules. 

The  modularization  we  present  here  is  intended  for  writing  and  for 
memory  management.  In  the  first  case  we  wish  to  reduce  the  number  of 
assumptions  one  module  writer  need  make  about  other  modules  [Pamas  71].  In 
the  second  case  we  wish  to  isolate  in  small  periods  of  time  the  references 
made  from  one  module  to  another  module.  We  attempt  to  do  both. 

The  importance  to  the  module  writer  of  a  complete  and  formal  specification 
of  the  module  environment  is  not  always  appreciated  by  project  managers.  The 
various  modules  of  a  compiler  communicate  via  inter-modular  data  structures. 

To  specify  a  module,  one  must  first  specify  the  data  structures  it  will  use 
and  then  specify  the  effect  the  module  will  have  on  those  structures.  One 
such  class  of  data  structures  consists  of  tables  built  by  one  module  and  used 
without  further  modification  by  other  modules.  Another  class  consists  of 
intermediate  languages  passed  from  one  module  to  the  next.  Taken  together, 
these  data  types  are  sufficient  for  convenient  compiler  writing  while  providing 
an  easily  understood  basis  for  specifying  the  functions  of  modules. 

If  we  have  a  specification  of  a  module  and  its  environment,  we  can  "fake 
up"  an  artificial  environment  in  which  to  test  the  module  separately  from 
all  other  modules.  While  preparing  an  exhaustive  test  may  take  as  much  time 
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as  writing  the  module,  experience  has  shown  the  extra  effort  worthwhile. 

In  the  following  pages  we  shall  exhibit  a  rather  elaborate  compiler 
organization.  Both  because  there  will  be  a  large  number  of  modules,  and 
because  the  exact  specification  of  a  particular  module  is  usually  source  or 
target  language  dependent,  it  is  inappropriate  to  attempt  a  complete 
description.  Instead  we  shall  sketch  the  overall  organization  and  give  a 
few  detailed  examples  of  specifications. 

Some  of  the  techniques  to  be  described  are  a  result  of  experiences 
with  the  XPL  compiler  generator  [McKeeman,  et.  al .  70].  Some  are  due  to 
the  various  recent  publications  in  structured  programming  [e.g.  Dijkstra  69]. 
Some  are  due  to  popular  compilers  such  as  the  Burroughs  B5500  Algol  and 
the  IBM  F-level  PL/1.  Some  are  to  ideas  in  optimization  [e.g.  Allen  71]. 

Many  are  found  in  David  Gries'  excellent  book  [71].  The  main  purpose  of 
this  paper  is  put  all  of  them  into  perspective  by  combining  them  in  a 
coherent  organization. 

Although  the  author  has  written  one  compiler  to  approximately  the 
prescription  advocated  in  the  following  pages,  the  ideas  therein  must  be 
regarded  as  tested  in  principle  rather  than  in  detail.  In  particular, 
the  module  environment  was  not  formally  documented  in  the  final  stages  of 
the  implementation. 

2,  THE  OVERALL  STRUCTURE  OF  A  COMPILER 

Our  description  proceeds  in  three  stages.  First  we  will  describe  a 
series  of  modules,  the  first  of  which  accepts  the  source  program  and  the  last 
of  which  produces  a  loadable  compiled  image.  Each  module  in  the  series 
accepts  as  input  the  output  of  the  previous  module,  thus  they  may  be  utili¬ 
zed  in  the  fashion  of  conventional  "passes"  or  "phases". 
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Second,  we  will  further  fragment  one  of  these  modules  into  a  set  of 
modules,  each  of  which  processes  a  specific  set  of  language  constructs. 

The  general  structure  of  the  compiler  is  shown  in  Figure  2.1.  The 
boxes  represent  modules  and  the  dotted  connecting  paths  of  the  intermodular 
data  flow.  The  larger  box  delineates  the  boundary  of  the  one  module  which 
is  further  fragmented  as  mentioned  above. 

For  reasons  that  are  obvious,  we  call  the  first  kind  of  modularization 
vertical  fragmentation,  and  the  second  kind  horizontal  fragmentation. 

And  third  we  will  consider  the  intermediate  language  texts  connecting 
the  modules  as  computational  objects.  In  many  cases  we  can  perform  trans¬ 
formations  on  intermediate  language  texts  which  produce  texts  in  the  same 
intermediate  language,  leaving  the  meaning  unchanged,  and  either  simplifying 
the  task  of  later  modules  or  improving  the  quality  of  the  eventual  target 
text.  We  call  these  processes  equivalence  transformations  and  implement 
them  as  modules  to  be  inserted  between  the  various  modules  in  the  vertical 


and  horizontal  sets. 
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The  general  pattern  of  data  flow  between  compiler  modules. 

Figure  2 . 1 
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We  will  use  a  notation  combining  the  context-free  grammars  of  Rohl  [68] 
and  the  regular  expression  operators  for  language  and  table  description. 

Rohl's  notion  of  quoting  terminal  symbols  allows  us  to  describe  languages 
while  avoiding  any  confusion  between  the  symbols  of  the  language  and  the  meta¬ 
symbols  of  the  grammar. 

When  we  describe  the  intermodular  data  structures,  we  must  include  not 
only  the  information  which  obviously  reflects  the  constructs  of  the  source 
text,  but  also  information  to  keep  the  modules  synchronized.  In  a  monolithic 
compiler  resident  in  main  memory,  much  of  the  synchronization  can  be  implicit 
and  the  intermediate  languages  can  be  represented  as  a  series  of  states  of 
variables  and  parameters.  Thus  the  language  descriptions  we  will  give 
specify  the  content,  rather  than  the  form,  of  the  intermodular  communication. 

Each  module  is  responsible  for  only  part  of  the  full  compilation  process, 
thus  each  module  needs  analyze  only  part  of  the  full  source  language  structure. 
The  grammars  for  the  intermodular  data  structures,  by  ignoring  some  structure, 
describe  languages  and  tables  which  contain  all  error-free  texts  as  well  as 
some  that  are  eventually  going  to  be  found  to  be  incorrect.  The  advantage  is 
in  keeping  each  step  simple;  one  result  is  that  structural  errors  in  the 
source  language  may  be  detected  at  any  stage  of  the  process;  another  result 
is  having  two  grammars  for  each  intermediate  language.  The  producing  module, 
having  processed  the  structure  it  needs,  tends  to  see  its  product  as  a  simple 
sequence  of  symbols.  The  consuming  module,  however,  will  detect  further 
structure  and  thus  benefit  from  a  more  elaborate  grammar.  The  difference 
between  two  such  languages  defines  one  class  of  diagnostics  issued  by  the 
consuming  module. 
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3.  VERTICAL  FRAGMENTATION 


There  are  seven  modules,  a  source  language,  a  target  language  and 
six  intermediate  languages  in  the  vertical  fragementation  depicted  in 
Figure  3 . 1 (a) . 
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Figure  3.1(a) 


The  tasks  of  the  modules  are  conventional.  INPUT  deals  with  the  input 
device,  sorts  out  control  cards,  detects  and  deletes  characters  that  are  not 
meaningful  in  the  source  language  and  handles  the  problems  associated  with 
breaking  text  across  record  boundaries.  INPUT  produces  a  sequence  of 
characters  for  further  processing;  it  may  also  issue  diagnostics  and  produce 
a  source  text  listing. 
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SCAN  accepts  the  sequence  of  characters  and  produces  a  sequence  of 
meaningful  symbols  called  tokens.  In  addition  to  discarding  superfluous 
material  such  as  comments  and  blanks,  SCAN  may  also  convert  constants  to 
internal  form  and  issue  diagnostics  of  its  own.  There  are  several  options  for 
the  output  from  SCAN.  If  a  table  of  strings  is  built  and  passed  along,  the 
token  string  can  be  represented  by  a  sequence  of  pointers  into  the  table. 
Otherwise  the  strings  themselves  can  be  passed.  If  later  diagnostics 
are  going  to  be  located  relative  to  the  source  text,  a  cummulative  column 
count  or  card  number  must  be  associated  with  each  token. 

The  intermediate  language  connecting  the  INPUT  module  to  the  SCAN 
module  is  a  sequence  of  characters.  From  the  viewpoint  of  INPUT,  the  inter¬ 
mediate  language  is  described  adequately  in  Figure  3.1(b).  From  the  viewpoint 
of  SCAN,  however,  the  grammar  in  Figure  3.2  is  more  appropriate. 

j 

! 

characters  =  character  *; 

i 

I 

.  . 

character  =  letter  |  digit  [  separator  ; 
letter  =  'A'  |  'B'  |  T C '  etc. 
digit  =  ’O'  |  *  1 f  |  ’2'  etc. 

|  separator  =  1  '  |  ’(’  |  ’+’  etc. 

! 

j  Figure  3.1(b)  The  Character  String  . 
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characters  =  token  list  ; 
token  list  = 


listl 

list2 

lis  t3 

| list4; 

listl  =  (| 

lis  t2 

|  list3 

| list4)  identifier  ; 

list2  =  (| 

lis  t3 

|  list4 

integer  ; 

list3  =  (| 

listl 

|  list2 

list4)  string  ; 

lis t4  =  ( | 

token 

list)  separator  ; 

identifier  =  letter  (letter  |  digit)*  ;  j 

I 

integer  =  digit  +; 

j 

string  =  ' ' ' '  string  character  *  ' ' 1 1  ; 
string  character  =  f ' f '  1 ' r '  |  character  ; 

i  i 

| 

l  ||  j 

I  character  =  letter  |  digit  |  separator  ;  j 

|  letter  =  'A'  etc. 

i  , 

digit  =  'O’  etc. 

i  i 

f 

]  j 

separator  =  '  T  etc.,  not  including  apostrophe.  } 

i  I 

\ 

i  j 

\ 

A  Lexical  Grammar 
j _  Figure  3.2 

Figure  3.3  describes  one  possible  form  of  the  output  from  SCAN,  right 
down  to  the  details  of  encoding  the  entries.  The  string  table  contains 
a  length  field  (8  bits)  preceding  the  actual  characters  (of  which  there  are 
at  most  255  per  string) .  The  tokens  contain  a  type  (discovered  by  SCAN) , 
the  location  of  the  token  in  the  source  text  and  a  pointer  into  the  string 


tab le . 
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string  table  =  entry  *  ; 
entry  =  length  value  ; 
length  =  (  'O'  |  '  1 ' )  8  ; 
value  =  character  *  ; 

character  =  letter  |  digit  |  separator  ;  etc. 

tokens  =  token  *  ; 

token  =  type  location  pointer  ; 

type  =  predefined  [  identifier  |  integer  |  string  ; 
predefined  =  '00'  ; 

identifier  =  '01'  ;  i 

integer  =  ' 10 '  ;  ! 

string  =  'll’  ; 
location  =  ('O'  |  '1')  16  ; 

\ 

j 

pointer  =  (’O'  |  '  1’)  16  ; 


A  String  Table  and 
Token  List  Grammar 

Figure  3.3 


Further  description  at  the  foregoing  level  of  detail  is  beyond  the 
scope  of  this  paper.  We  shall  therefore  conclude  this  section  with  Figures 
3.4  depicting  eight  successive  stages  of  a  sample  text  as  it  passed  from 
module  to  module.  It  is  left  to  the  reader  to  deduce  the  general  picture 
from  the  particular  example. 


1  THEN  X=53  +  X 
IF  X  <= 


T 


source  text 
Figure  3.4(a) 


IF  X  <-  1  THEN  X=53-  +  X 


characters 
Figure  3.4(b) 
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Figure  3.4(c) 
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phrase  structure  tree 
Figure  3.4(d) 


-12- 


I 


[ 


LE  STORE 

!  7\ 

XI  X  ApD 

/  \ 

53  xX 


computation  tree 
Figure  3.4(e) 

i 

i 


3 

i 

; 


LIT  X;  LOAD;  LIT  1;  LE; 

LIT  $Ll;  BRANCH JFALSE;  LIT  X; 

LIT  53;  LIT  X;  LOAD;  ADD;  $L1: 

zero-address  code 
Figure  3.4(f) 


LOAD  X;  SUB  =1;  BRANCH_POSITIVE  $L1; 

LOAD  =53;  ADD  X;  STORE  X;  $L1: 

single-address  code 
Figure  3.4(g) 


5810D0405B10D0444740E124 

411000375A10D0405010D040 

machine  code 
Figure  3.4(h) 


4.  HORIZONTAL  FRAGMENTATION 

The  PARSE  module  produces  an  intermediate  form  that  reveals  the  largest 
proportion  of  the  source  text  structure.  There  is  nothing  particularly  start¬ 
ling  in  this;  it  simply  reflects  the  fact  that  we  tend  to  use  a  single  grammar  to 
specify  all  that  structure.  Nevertheless,  there  is  considerable  advantage  in 
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fragmenting  the  module  which  must  process  all  of  this  information. 

A  well-designed  source  language  allows  the  compiler  writer  to  place 
any  particular  piece  of  source  text  structure  in  one  of  five  classes.  It 
is  either  definitional  in  nature  (e.g.,  declarations),  or  specifies  an 
an  operand  (e.g.,  addition),  or  specifies  an  assignment,  or  specifies  some 
kind  of  sequence  control.  Furthermore,  well-written  source  programs  tend 
to  have  long  sequences  of  text  with  structure  that  lies  entirely  in  one  class. 

The  output  of  PARSE  is  either  a  phrase-structure  tree  (e.g..  Figure 
3.4(e))  or  the  canonical  parse  [Wirth  §  Weber  66].  The  output  of  SYNTHESIS 
is  a  computation  tree*  or  a  sequence  of  action  codes. 

The  modules  and  data  flow  of  a  horizontal  fragmentation  are  shown  in 
Figure  4.1.  The  FAN_OUT  module  passes  the  appropriate  parts  of  the  phrase- 
structure  tree  or  canonical  parse  to  the  modules  below.  The  FAN_IN  module 
recombines  them  (via  implicit  or  explicit  synchronization  information)  into 
a  computation  tree  or  a  sequence  of  actions.  It  may  be  convenient  to  inter¬ 
pose  some  of  the  equivalence  transformations  described  in  Section  5  just 

ahead  of  the  FAN_IN  module. 

. .  - 

-  -  ^Ffan  out  _ 

J  —  "  -  /  N 

_ _ %  _ _.v| _ ^  _ _ 

!  NULL  DEFINE  OPERAND  j  j OPERATE  j  ASSIGN  SEQUENCE 


"  symbol!  '  \  .  - 

TABLE 

-V'L  L.'  ;  ■' 

j  FAN  IN  j 

'  | 

A  Horizontal  Fragmentation  of  Synthesis 
Figure  4.1 


*  Frank  DeRemer  calls  the  tree  in  Figure  5.2  the  abstract  syntax  tree.  The 
transformation  from  phrase-structure  tree  to  syntax  tree  can  be  formalized 
to  the  point  of  allowing  the  compiler  writer  to  specify  it  in  tabular  form, 
thus  avoiding  the  rather  messy  task  of  manipulating  the  full  tree  directly. 
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Figure  4.2  contains  a  grammar  for  an  action  code  language  suitable 
for  output  from  SEQUENCE.  Only  minor  modifications  are  needed  to  transform 
the  action  codes  into  language-specific  sequential  codes.  The  sequence 
code  is  synchronized  with  other  statements  by  the  pointers  which  locate  the 
statements  in  the  other  intermediate  languages. 


segment  =  statement  *  ; 
statement  =  pointer  |  branch 
condition 

loop_begin  segment  loop  end 
casejbegin  case  *  case_end  ; 
branch  =  local  return  |  label  return 
local_repeat  |  label  repeat  ; 
label  =  pointer  ; 
condition  =  pointer  if  branch 
statement  then  branch 
statement  else_fixup  ; 
loop_end  =  local_repeat  end  ; 
case  =  case  fixup  statement  local_return  ; 
pointer  =  ('0?  |  '1')  16; 

loop_begin  =  'O'  ; 
end  =  ' 1 f  ; 
case_begin  =  *2'  ; 
case_end  =  '3'  ; 
local_retum  =  '4'  ; 
return  =  '5'  ; 
local_repeat  =  *6'  ; 
repeat  =  '7'  ; 
if_branch  =  '8'  ; 
thenjbranch  =  '9'  ; 
else-fixup  =  T 10 f  ; 

Action  Code  Language  from  SEQUENCE 
Figure  4.2 


Figure  4.3  contains  a  grammar  for  an  action  code  suitable  for  the 
declarations  of  a  source  text  in  a  subset  of  PL/I.  As  an  output  from 
DEFINE,  such  actions  would  usually  be  used  to  build  a  symbol  table  such  as 
is  described  in  Figure  4.4. 
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scope  =  scope_begin  entry  *  scope  end 
entry  =  scope  |  item; 
item  =  new_name  |  attribute  ; 
new_name  =  enter  pointer  ; 
attribute  = 

type  (fixed  |  bit  |  character  |  label) 

dimensions  integer  ; 
integer  =  digit  +  ; 
scope_begin  =  'O'  ; 
s  cope_end  =  ' 1 '  ; 
enter  =  *2’  ; 
type  =  '3'  ; 
dimensions  =  ’4'  ; 
fixed  =  ?0'  ; 
bit  =  '1'  ; 
character  =  '2*  ; 
label  =  '3'  ; 

Action  Code  Language  from  DEFINE 
Figure  4.3 


symbol_table  =  entry  *  ; 
entry  =  name  attributes  ; 
name  =  pointer  ; 
attributes  = 

data_type  dimension  address  | 
label_type  parameter_count  address  ; 
data_type  =  fixed  |  bit  |  character  ; 
dimension  =  integer; 
parameter_count  =  integer  ; 
address  =  base  displacement  ; 
base  =  (’O'  |  *  1 f )  4  ; 
displacement  =  ('O'  1 1  * )  12  ; 

etc. 

Symbol  Table  Grammar 
Figure  4.4 


The  techniques  of  horizontal  fragmentation  should  now  be  clear.  The 
various  examples  given  are  intended  to  serve  as  a  guide  to  the  general  method 
but  by  no  means  should  the  details  be  taken  as  absolute.  There  are  a  great 
number  of  options.  The  choice  between  them  depends  on  the  particular  re¬ 
quirements  of  a  given  implementation. 
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5.  EQUIVALENCE  TRANSFORMATIONS 

Any  of  the  intermediate  languages  is  a  candidate  for  equivalence 
transformations.  And  each  particular  transformation  can  usually  be  done 
on  any  one  of  several  intermediate  languages.  The  major  problems  are 
deciding  if  a  particular  transformation  is  worthwhile  and  on  which  inter¬ 
mediate  language  it  is  most  convenient  to  carry  it  out. 

Translating  a  very  complex  language  (e.g.,  the  IBM  PL/ 1)  can  be 

* 

simplified  by  passing  repeatedly  over  the  token  string,  each  time  producing 
an  equivalent  token  string  with  fewer  primitive  concepts.  The  final  set 
of  primitives  is  usually  taken  to  include  GO  TO,  IF,  assignments  and  other 
things  that  map  directly  onto  a  conventional  instruction  set. 

Figure  5.1  displays  three  successive  equivalence  transformations  on  a 
PL/1  program.  Initially  there  is  an  array  assignment  which  implies  a 
loop  (stage  2) .  The  translator  has  had  to  create  some  new  identifiers 
(which  are  started  with  '$’  to  avoid  confusion).  The  control  expressions 
of  the  do- loop  are  evaluated  only  once  implying  that  the  head  of  the  loop 
contains  only  simple  variables  (stage  3) .  The  loop  itself  can  then  be 
factored  into  IF  and  GO  TO  constructs  (stage  4) . 

The  advantages  are  the  already  mentioned  reduction  in  overall  trans¬ 
lator  complexity  and  also  the  fragmentation  of  the  translator  to  aid  in 
making  each  piece  small  enough  to  permit  running  in  a  small  memory.  It 
has  some  utility  in  documenting  the  meaning  of  language  constructs  where 
the  transformations  are  simple  enough  to  be  easily  understood. 

The  technique  has  some  disadvantages.  It  can  be  slow  since  repeated 
passes  over  the  token  string  are  required.  Clever  methods  of  speeding 
things  up  may  cancel  the  gain  in  simplicity  that  led  to  its  use  in  the  first 
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place.  There  is  also  a  lack  of  theory  governing  the  transformations, 
leaving  a  potentially  confusing  series  of  ad-hoc  algorithms.  Finally, 
the  transformations  may  obscure  relations  that  would  have  been  useful 
to  the  generators.  For  instance,  the  fact  that  the  example  in  Figure  5.1 
can  be  accomplished  with  a  single  memory  to  memory  block  transfer  instruction 
will  never  be  recovered  from  the  simplified  form  at  stage  4. 


DECLARE  (A, B)  (20)  FIXED; 
A  =  B; 


DECLARE  (A,B)  (20)  FIXED; 

DECLARE  $11  FIXED; 

DO  $11  =  LBOUND(A)  TO  HBOUND (A) ; 
A($I1)  =  3($I1) ; 

END 


DECLARE  (A, B)  (20)  FIXED; 

DECLARE  ($11,  $12,  $13,  $14)  FIXED; 
$12  =  LBOUND(A) ; 

$13  =  1; 

$14  =  HBOUND (A); 

DO  $11  =  $12  BY  $13  TO  $14; 

A($I 1)  =  B  ($1 1) ; 

END; 


DECLARE  (A, B)  (20)  FIXED; 

DECLARE  ($11,  $12,  $13,  $14)  FIXED; 

$12  =  LBOUND(A) ; 

$13  =  1; 

$14  =  HBOUND (A); 

$11  =  $12; 

$15:  IF  $11  >  $12  THEN  GO  TO  $16; 

A($I 1)  =  B ($1 1) ; 

$11  =  $11  +  1; 

GO  TO  $15; 

$16: 

Successive  Transformations  of  a  PL/I  Program  Fragment 

Figure  5 . 1 


-18- 


The  computation  tree,  since  it  exhibits  almost  all  of  the  meaningful 
source  language  structure,  may  also  be  a  convenient  host  for  equivalence 
transformations.  Figure  5.2  depicts  a  before  and  after  view  of  a  small 
computation  tree  in  which  a  (presumably  expensive)  multiply  has  been 
transformed  into  an  addition. 


STORE 


REPEAT 


r 


l 


SEQ 


STORE 
I  /  ADD 

f  \ 

I  2 


IF 

i 

GT 


RETURN  NULL 


NfUL  ADD 

\  / 

%  /  \ 

3  I  99 


SEQ 

STORE  STORE 

\ 

I  1  $11  "9 

STORE  IF 

\ 

I  x  ADD 

I  2 


-  REPEAT 
SEQ 
STORE 

I 

$1 1  ADD 

/  \ 

$11  X6 


GT  RETURN  NULL 
$I1XADD 

'X 

I  99 


A  Before  and  After  View  of  the 
Computation 
I  =  1; 

DO  FOREVER; 

1=1+2; 

IF  1*3  >  1+99  THEN  RETURN; 
END; 


Figure  5.2 
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Tree  transformations  consume  more  computational  resources  than 
most  other  phases  of  translation  both  because  the  tree  occupies  a  lot 
of  memory  and  following  the  links  takes  a  lot  of  time.  It  may  also  be 
that  the  transformation  causes  a  new  inefficiency  to  be  introduced  as  a 
result  of  successfully  ridding  the  program  of  the  one  being  attacked. 

Thus  the  implementor  must  be  careful  in  deciding  which  transformations 
are  economically  justified.  Tree  transformations  are  easier  to  carry  out 
when  the  source  language  does  not  include  a  GO  TO  construct  to  break  up 
sequences  of  code,  thereby  making  difficult  the  detection  of  induction 
variables  and  the  like. 

Most  computers  have  peculiarities  that  are  utilized  by  assembly 
language  programmers  but  are  not  directly  available  to  the  compiler, 
partly  because  the  opportunities  to  make  use  of  them  do  not  become  apparent 
until  after  the  machine  code  itself  has  been  emitted,  and  partly  because 
they  are  special  to  the  target  machine  in  question  [McKeeman  65].  Table 
5.3  shows  a  typical  situation  of  this  kind.  At  stage  1  we  have  a  good 
machine  code  for  the  two  statements.  Because  addition  is  commutative, 
the  addresses  of  a  pair,  LOAD  ADD,  can  be  interchanged  (stage  2)  which 
permits  the  slow  LOAD  =1  to  be  replaced  with  a  fast  load  immediate  LI  1 
and  also  saves  the  cell  containing  the  constant  1  (stage  3).  In  any  pair, 

STORE  X  LOAD  X,  the  LOAD  can  be  dropped  if  it  is  not  the  destination  of  a 
branch  (stage  4).  Any  pair  of  branches,  where  the  first  is  a  conditional 
skip  and  the  second  is  unconditional  can  be  reduced  to  a  single  conditional 
branch  (stage  5).  Finally,  on  a  machine  with  an  add-one- to-memory  instruction, 
the  sequence  LI  1,  ADD  X,  STORE  X  can  be  combined  into  one  instruction 
(stage  6) . 
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Stage  1 

LOAD  X 

ADD  =1 

STORE  X 

LOAD  X 

LT  =3 

BRANCH  FALSE  $L1 

BRANCH  L 

$L1: 

Stage  2 

LOAD  =1 

ADD  X 

STORE  X 

LOAD  X 

LT  =3 

BRANCH  FALSE  $L1 
BRANCH  L 
$L1 : 

Stage  3 

LI  1 

ADD  X 

STORE  X 

LOAD  X 

LT  =3 

BRANCH  FALSE  $L1 
BRANCH  L 
$L1 : 

Stage  4 

LI  1 

ADD  X 

STORE  X 

LOAD  X 

LT  =3 

BRANCH  FALSE  $L1 
BRANCH  L 
$L1 : 

Stage  5 

LI  1 

ADD  X 

STORE  X 

LT  =3 

BRANCHJTRUE  L 

Stage  6 

INDEX  X 

LT  =3 

BRANCH. TRUE  L 

Figure  5.3 
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Figure  5.3  depicts  the  machine-specific  transformations  on  a  single¬ 
address  code  for 

X  =  X+l;  IF  X  <  3  THEN  GO  TO  L; 

Innumerable  such  ingenuities  can  be  applied.  Since  the  savings  can  be 
dramatic  (as  in  the  last  example) ,  the  technique  is  useful  and  popular. 
Nothing  makes  the  hero- author  of  a  compiler  happier  than  producing 
really  subtle  correct  code,  beating  the  assembly  programmer  at  his  own  game. 
One  must,  however,  guard  against  introducing  errors  into  the  code  as  a 
result  of  not  carefully  considering  the  conditions  under  which  the  trans¬ 
formations  leave  the  program  invariant. 

6.  SUMMARY 

There  are  many  reasons  to  want  to  break  a  compiler  into  pieces.  The 
ability  to  run  the  translator  in  a  small  memory  is  one  which  the  computer 
salesman  and  computer  purchasers  feel  important.  The  problems  of  managing 
large  programming  projects  have  demanded  a  task  organization  which  results 
in  many  small  well-defined  subtasks.  Further,  there  seems  to  be  a  definite 
limit  on  how  complex  a  task  can  be  attempted  without  incurring  exponentially 
growing  delays  and  costs.  There  even  seems  to  be  a  critical  size  beyond 
which  repairing  an  error  introduces  on  the  average  of  more  than  one  error 
[Lehman  71].  And,  finally,  no  matter  how  well  a  system  seems  to  perform, 
it  is  good  engineering  practice  to  know  how  well  and  under  what  range  of 
conditions  the  system  will  perform. 

Such  knowledge  comes  from  understanding,  understanding  comes  from 
not  having  to  consider  something  complex  all  in  one  mental  step. 

There  are  some  principles  that  guide  the  choice  of  natural  boundaries 
between  program  modules.  A  boundary  is  good  if  there  are  few  references 
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across  it  into  other  modules  and  those  references  are  relatively  in¬ 
frequently  exercised.  A  boundary  is  good  if  the  information  flow  through 
it  can  be  simply  described.  A  module  is  good  if  its  function  can  be 
simply  described.  A  data  flow  is  good  if  it  can  be  totally  produced 
before  any  of  it  is  consumed  (meaning  no  feedback  is  needed  across  the 
boundary) .  A  set  of  modules  is  good  if  execution  activity  can  be  isolated 
in  small  subsets  (working  sets)  over  substantial  spans  of  time.  And  such 
a  set  is  well-designed  if  particular  dependencies  are  isolated  in  small 
subsets.  It  is  also  of  value  if  one  module  can  be  changed  without  involving 
the  processing  of  many  other  modules.  We  can  suppress  detail  by  considering 
a  subset  of  the  modules  as  a  single  module  where  the  internal  data  trans¬ 
actions  and  control  transfers  are  ignored.  The  boundary  around  such  a 
supermodule  is  good  if  the  resulting  module  obeys  the  rules  above. 

The  techniques  of  engineering  compilers  are  being  developed.  The 
time  should  soon  come  when  compilers  are  well-engineered  as  a  rule,  not 
as  an  exception. 


The  work  reported  here  was  supported  by  the  Computer  Systems  Research  Group 
and  the  Computer  Science  Department  at  the  University  of  Toronto. 
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